Final Project Report Format

Overview of Report Format:

The final project report should begin with an abstract and contain a problem statement, brief motivation for the problem, discussion of the specific sub-problems that were addressed, detailed discussion of your pro­posed algorithm(s), experimental results, and references. In addition, you should provide some comparison versus other approaches to solve the same problem where the comparison may be experimental or simply a discussion. Don’t forget to conclude the project with the future work proposed. Also mention the limitations of your algorithm and the assumptions. Finally, you should include an Appendix with any code written for the project.

 

QA Format:

Writing a document like a one long sequence of paragraphs, with no internal structure, is not an effective way to communicate.

I want all reports or chapters in Question Answer format. Each question and answer should be a paragraph. Doing it in question answer format will maintain a smooth flow to the content in the report.QA format will also help you think logically. The sections become a roadmap for the reader, making it clear what aspect of the project you are discussing at each point in the paper.

 

Abstract: The basic idea

What is this project about? This is not a complete product specification. It is a concise description of the idea, but with enough detail to make it absolutely clear what is being attempted.

 

Introduction:

Who will use this product/algorithm? Why do they need it? What do they use now? What makes the problem you are solving so difficult? What is the importance of the solution of his problem? What will be possible with your product that isn't possible now?

 

What has already been done in this area? What are the strengths and weaknesses of existing products? What areas have not been addressed? If this is a brand new idea, how does it relate to existing products, and why hasn't it been done before? Are there any commercial products available?

 

Algorithm Description:

Include the block diagram, flowchart or the detailed description of your algorithm. Briefly describe the theory or the part of the theory involved in the algorithm. If the theory is too vast, create a separate chapter for the theory.

 

Experimentation:

Include a list of the experiments you have performed. Explain why you choose to perform those experiments or the significance of these experiments. Discuss the results of the experiments. Explain what you expected and what you observed. Did your expectations match the results? If not, why?

 

Performance:

Include the MATLAB plots to show the performance figures. Include as many tables and figures as possible.

 

Conclusion and Future work:

There are two targeted goals behind the implementation of a particular approach. The first goal is to verify that the approach works. Towards this goal, each student is expected to test his/her implementation. The second and most important goal is to identify weak points of the approach, that is, to identify under what circumstances the approach will fail to produce good results and demonstrate this using data that actually make the approach fail or perform very poor. Identifying cases that cause problems to an approach is very important since somebody can develop superior approaches (e.g., by improving an existing approach or by proposing a new approach) to handle these cases success­ fully. Propose solutions to alleviate these problems.

 

References:

Please give references in IEEE format whenever you are cut and pasting from a paper. In addition to listing the reference in IEEE format I want u to give me the website for that paper too so I can go download it and refer it.  

 

Appendix:

If you are extending or changing a program from another source, you should document where the original program came
from and how it is being altered. You must document EXACTLY which compiler (including version) and what operating 
system you used. You must give PRECISE instructions (including compiler options and required libraries, if relevant) as to 
                                                       how to build the project. Also include documentation or a user manual giving a description of the functions implemented e.g.
 

readImage(filename, image) Reads in an image from a file. The pixel values are stored in an  array and the image width, height, and number of gray levels are recorded in the appropriate fields. A NOT­PGM exception should be raised if the image file to be read is not in PGM format (image is an object of type Image).

 

writeImage(filename, image): Writes out an image to a file in the appropriate format (image is  an object of type Image).

 
Document the purpose of the function, the arguments passed, the precondition and the post condition in the user manual. The source files should be well documented. There should be a README file that explains how to build the project and gives the user instructions on how to use the program and on its limitations. Follow the C/C++ standard
provided to u.UML diagrams for code is compulsory  
 
Length of report:
  A good report is not which has more pages but one which has more information.
Doesnt matter if the report is 4 pages or 10 pages or 100  pages. I prefer you giving me a report full of information 
even though its 4 pages but you should know each and every word you have written in it. Please dont write anything 
in the report which you yourself dont understand. 

 
What to submit in the project?
All the files needed to build the project should be there i.e. all source files (.c, .cpp, .h, .rc, .bmp, .ico, etc.), project/workspace 
files (.dsp, .dsw, etc.), including any DLLs. Don’t send the executable. I will use the README file provided by you to create the .exe
 
How to submit the project?
If your project is too big even after compressing the files using Winzip, an alternative, 
if you have access to a burner, would be to put it onto a CD-ROM. You can email the file if it is less than
4 MB or use FTP.